1. Field of the Invention
The present invention generally relates to data processing and more particularly redundant request processing.
2. Description of the Related Art
In the context of a computerized environment, applications perform a variety of functions. Well known uses for applications include word processing, servicing Web requests, generating queries to be issued against databases, performing business transactions and the like.
In a typical application, a request (e.g., a user request) is received by an action router (event handler). Based on the data included with the user request the action router determines which function of the application (the “application action function”) will handle the user request. In some cases the application action function calls a user interface renderer to display the appropriate output to the user. Throughout the processing of the request the application maintains state information. State information is the information that the application builds and uses during request processing. Such information includes application variables and their values for tracking who the user is, what they are doing and what they can do next during subsequent processing. For example, state information may include (but is not limited to) a user identification (ID) and password that the user authenticates with, the visual representation of a current user interface being presented to the user (e.g., whether the interface is terse or verbose, the absence or presence of a taskbar, and other preferences), contents of a shopping cart, and the history of user requests.
The foregoing generally describes the processing performed by an application. Of course, variations exist between applications. Some differences between applications may be characterized as differences in complexity. For example, Web applications are relatively unique in that, with respect to other applications, they have a more well restricted and encapsulated definition of their flow (as viewed from outside the application). A Web application's flow can be completely articulated by a series of requests for Uniform Resource Locators (URLs) and parameters passed on those requests that a client makes. Other applications may require more complex and encompassing representations to fully articulate the flow through the application. For example, application memory and register contents may need to be described in addition to the Application Program Interface (API) calls and parameters passed by the application.
In any case, all applications inevitably encounter errors. The possible source of these errors is highly varied, thereby making it difficult for users to take appropriate corrective action (if any corrective action is possible). The process of identifying the source of errors (and in some cases correcting errors) in applications is referred to as debugging. Debugging generally refers to a variety of techniques for addressing errors. Well-known debugging techniques include tracing, dumping and specific error handling/recovery. Tracing is useful in addressing consistent logic errors and user errors in application flow and, as such, may be a good solution for a broad category of problem determination and service. Typically, tracing is used in a fashion that allows the tracing facility to be turned on by the user when requested (i.e., end the application and restart it with tracing turned on), or by tracing information after an unexpected error occurs.
Dumping is performed upon the occurrence of an error. A file is created containing the contents of memory, request, data structures, etc., that are currently being used by the application. This provides the user a “snapshot” of what is going on in the application and a given point in time. Depending upon the resources and implementation, the snapshot may focus on small sections of the application (e.g., a particular data structure), the entire application state (e.g., a UNIX core file) and many areas therebetween.
Specific error handling/recovery code is very common in applications. Such code is configured to handle possible errors that might occur under certain conditions, give the user feedback about the error condition, and provide the user with alternatives. Expected errors might be “file not found”, in which case the user can retry with a new location or filename.
However, existing debugging techniques suffer from various disadvantages. For example, tracing strategies tend to be very inefficient from a performance perspective. Further, tracing does not allow users to automatically avoid the error condition(s) nor does it facilitate re-creating problem scenarios that might be caused by outside influences. Dumping is a substantially limited solution in that it is after the fact and does not at all facilitate determining the symptoms leading up to the problem. As such, dumping does not allow a user to determine how the problem may be avoided in the future (should the same conditions be present again). In the case of specific error handling/recovery code, generic code may be written that simply handles any unexpected errors, presenting appropriate error information (collecting trace or dumb files) and directing the user to try again (or perhaps not, because the error was unexpected). Accordingly, such error handling/recovery code is very limited in its ability to allow users to identify and react to the particular conditions giving rise to a particular problem.
Therefore, there is a need for a method, apparatus and article of manufacture for service and/or recovery from application errors.